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ABSTRACT 

The  Royal  Australian  Navy  (RAN)  uses  Standard  Operating  Procedures  (SOP)  to  record 
standard  practices  on  individual  ships.  SOPs  are  usually  written  as  descriptive  documents 
covering  the  rules  to  be  followed  when  performing  ship  activities.  It  has  been  observed  that 
this  style  of  document  does  not  provide  crews  the  required  guidance  in  a  clear  and  easy  to  use 
form,  or  for  the  RAN  Test  Evaluation  and  Analysis  Authority  to  use  when  assessing  crew 
performance.  DST  Group  was  requested  to  improve  the  situation  and  develop  a  robust 
methodology  tailored  to  the  RAN  for  creating  SOPs  using  flow  diagrams.  This  report  covers 
the  issues  with  the  current  RAN  style  of  SOP  and  details  the  developed  methodology  of  using 
flow  diagrams  that  was  piloted  on  HMAS  Canberra. 
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Creating  Royal  Australian  Navy  Standard  Operating 
Procedures  using  Flow  Diagrams 

Executive  Summary 


The  Royal  Australian  Navy  (RAN)  has  a  documentation  system  for  recording  and 
disseminating  operational  practices  on  ships.  Within  this  system  are  ship  Standard 
Operating  Procedures  (SOP),  which  describe  how  to  perform  a  set  activity  on  a 
particular  ship.  However,  as  observed  by  the  Royal  Australian  Navy  Test  and 
Evaluation  Analysis  Authority  (RANTEAA)  and  the  Defence  Science  and  Technology 
Group  (DST  Group)  the  current  form  of  RAN  SOP  does  not  provide  the  required 
information  in  a  form  that  is  easy  to  understand,  implement  or  assess. 

The  aim  of  a  ship  SOP  is  to  communicate  to  the  reader  in  sufficient  detail  a  description 
of  the  steps  that  should  be  performed  for  a  particular  activity  on  that  particular  ship. 
Current  RAN  SOPs  are  primarily  written  as  descriptive  documents  covering  the  rules 
that  should  be  followed  when  performing  a  set  activity.  There  is  minimal  control  over 
the  interpretation,  which  is  influenced  by  the  different  levels  of  ship  crew  experience 
and  knowledge.  Due  to  the  regular  crew  posting  cycle  the  interpretation  and 
application  of  the  rules  can  change  increasing  the  risks  to  safety  and  reducing  the 
ability  of  the  ship's  crew  to  perform  as  a  cohesive  unit.  Descriptive  rules  are  also 
difficult  to  use  for  teaching  or  for  assessing  crew  performance. 

Based  on  practices  adopted  by  businesses  the  flow  diagram  methodology  was 
recommended  as  an  improved  method  for  creating  SOPs.  This  methodology  involves 
using  symbols  and  lines  to  graphically  represent  the  order  and  flow  of  tasks  to  perform 
during  a  ship  activity.  This  is  then  enhanced  with  a  description  of  each  task  where 
details,  such  as  who  performs  the  task,  the  relevant  Safety  Risk  Profiles  and  required 
resources  are  documented.  Focussing  on  the  use  of  clear  and  succinct  language  tailored 
to  the  anticipated  audience  results  in  a  clear  and  easy  to  follow  procedure,  whilst 
maintaining  sufficient  background  information  to  enable  informed  changes  to  the 
procedure. 

Commander  Surface  Force  RAN  (COMSURFOR)  requested  DST  Group  develop  a 
method  for  creating  ship  SOPs  based  on  flow  diagrams  and  to  assist  the  first  RAN 
handing  Helicopter  Dock  ship's  (HMAS  Canberra)  crew  use  this  new  method.  DST 
Group  developed  a  robust  methodology,  described  in  this  report,  tailored  to  the  RAN 
that  produces  clear  and  easy  to  use  written  SOPs.  COMSURFOR,  supported  by 
RANTEAA,  plans  to  adopt  this  new  way  of  developing  SOPs  by  directing  its  use  across 
the  fleet. 
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1.  Introduction 


The  Royal  Australian  Navy  (RAN)  has  a  documentation  system  for  recording  and 
disseminating  operational  practices  on  ships.  Within  this  system  is  Standard  Operating 
Procedures  (SOP).  However,  as  observed  by  the  Royal  Australian  Navy  Test  and 
Evaluation  Analysis  Authority  (RANTEAA)  and  the  Defence  Science  and  Technology 
Group  (DST  Group)  the  current  style  of  RAN  SOP  does  not  provide  the  required 
information  in  a  form  that  is  easy  to  understand,  implement  or  assess. 

The  aim  of  a  ship  SOP  is  to  communicate  to  the  reader  in  sufficient  detail  a  description  of 
the  steps  that  should  be  performed  for  a  particular  activity  on  that  particular  ship.  SOPs 
cover  different  levels  of  ship  activities,  from  whole  ship  activities  down  to  an  individual's 
activities.  Current  RAN  SOPs  are  primarily  written  as  descriptive  documents  covering  the 
rules  that  should  be  followed  when  performing  a  set  activity.  This  leaves  the  application  of 
the  rules  open  to  interpretation.  There  is  minimal  control  over  the  interpretation,  which  is 
coloured  by  the  different  levels  of  experience  and  knowledge  of  those  using  them.  Due  to 
the  regular  crew  posting  cycle  the  application  of  the  rules  can  change  increasing  the  risks 
to  safety  and  reducing  the  ability  of  the  ship's  crew  to  perform  as  a  cohesive  unit. 
Descriptive  rules  are  also  difficult  to  use  for  teaching  or  to  assess  crew  performance 
against. 

For  these  reasons  Commander  Surface  Force  RAN  (COMSURFOR)  requested  DST  Group 
develop  a  method  for  creating  ship  SOPs  based  on  flow  diagrams  and  to  assist  the  first 
RAN  Landing  Helicopter  Dock  ship  (HMAS  Canberra )  crew  use  this  new  method.  This  was 
carried  out  during  2013. 

This  report  describes  the  intent  and  purpose  of  RAN  SOPs.  It  also  describes  why  changes 
are  required  to  existing  format  of  RAN  SOPs,  and  the  method  tailored  to  the  RAN  for 
developing  RAN  SOPs  based  on  flow  diagrams.  COMSURFOR,  supported  by  RANTEAA, 
plans  to  adopt  this  new  way  of  developing  SOPs  by  directing  its  use  across  the  fleet. 


2.  The  RAN  SOP 


The  RAN  uses  an  extensive  range  of  documents,  which  must  either  be  adhered  to  or  are 
guidance,  to  inform  RAN  personnel,  the  wider  Defence  Department  and  the  general 
community  on  its  strategy,  methods,  systems  and  requirements.  These  documents  are 
tailored  to  different  audiences  and,  for  the  Navy,  either  to  the  service  as  a  whole,  to  the 
Fleet  or  to  individual  ship  classes.  These  documents  form  a  contiguous  description  of 
operating  policies. 

RAN  ship  SOPs  sit  beside  the  Australian  Books  of  Reference  (ABRs)  and  the  DEF(AUST) 
5000  (ADF  Maritime  Material  Requirements  Set)  to  describe  in  detail  how  to  perform  an 
activity  using  the  available  ship  systems/ equipment.  ABRs  describe  the  'what'  of  the 
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activity  -  the  purpose  of  the  activity  and  how  the  activity  fits  into  the  broader  context  of  an 
operation.  ABRs  also  provide  the  rules  a  class  of  ship  or  the  entire  fleet  must  adhere  to 
when  performing  an  activity.  The  rules  address  safety  aspects  as  well  as  approval  and 
reporting  requirements. 

DEF(AUST)  5000  [1]  describes  in  detail  how  to  technically  use  a  system  or  piece  of 
equipment  safely.  DEF(AUST)  5000  also  includes  test  scenarios,  performance  measures 
and  values1.  The  Command  Information  section  of  DEF(AUST)50002  covers  the 
performance  of  the  system/ equipment,  its  limitations  and  warfare  implications.  The 
Operating  Instruction  section  details  the  operating  instructions  and  drill  for  the  operators 
of  the  system,  including  the  operational  interfaces  of  the  system  equipment  and  associated 
systems.  The  focus  is  the  safe  use  of  the  individual  system. 

Ship  SOPs  describe  how  to  implement  the  rules  in  ABRs  and  when  to  use  the 
systems/ equipment  detailed  in  DEF(AUST)  5000.  Importantly  ship  SOPs  must  adhere  to 
the  guidance  in  ABRs  and  DEF(AUST)  5000,  as  well  as  the  intent  in  higher  level  doctrinal 
documents. 


2.1  Issues  with  the  descriptive  style  of  RAN  SOP 

RAN  SOPs  have  traditionally  been  mainly  descriptive  documents  covering  the  ship  rules 
and  only  occasionally  covering  the  implementation  of  those  rules  (see  Appendix  A  for  an 
example  excerpt).  This  has  allowed  individuals  performing  an  activity  to  use  their 
experience  and  knowledge  to  be  flexible  when  performing  or  coordinating  an  activity.  The 
benefit  of  this  approach  has  been  the  scope  to  adapt  the  steps  based  upon  the 
circumstances.  The  disadvantage  is  each  new  person  performing  the  activity  must 
interpret  the  rules  and  determine  the  best  way  to  perform  the  activity.  The  'how'  must 
then  be  communicated  to  others  who  may  also  be  performing  the  activity  or  are  impacted 
by  it. 

Flow  well  the  activity  is  performed  is  heavily  influenced  by  the  person's  knowledge  and 
experience,  and  consequently  the  steps  performed  by  one  person  may  differ  significantly 
to  the  steps  performed  by  a  different  person.  For  a  simple  activity  that  is  self-contained,  as 
long  as  the  rules  are  adhered  to,  the  steps  performed  are  not  of  concern.  However,  the 
activities  on  ships  are  not  simple  and  rarely  are  they  self-contained  within  a  single 
department.  Purely  descriptive  SOPs  cannot  adequately  describe  the  impact  performing 
different  steps  within  an  activity  may  have  upon  other  ship  departments.  Consequently, 
there  is  an  increased  risk  that  interface  activities  to  synchronise  and  coordinate  activities 
between  departments  will  introduce  additional  overheads.  This  in  turn  increases  the  risks 
to  safety  and  reduces  the  ability  of  the  ship's  crew  to  perform  as  a  cohesive  unit. 


1  e.g.  DEF(AUST)  5000  Vol  7  Part  15,  Section  5  specifies  times  to  aim  for  in  evacuations  for  different 
weight  vessels  and  Vol  7  Pt  15,  Annex  B  attachment  1  contains  test  scenarios  for  evacuations. 

2  DEF(AUST)  5000  Vol  02  Part  18  Issue  01,  Section  5.9  describes  the  content  for  technical  system, 
sub-system  and  equipment  manuals. 


2 


UNCLASSIFIED 


UNCLASSIFIED 


DST-Group-TR-3137 


This  is  particularly  the  case  for  the  new  to  the  RAN  Canberra  class  Amphibious  Assault 
Ship,  also  known  as  a  Landing  Helicopter  Dock  (LHD)  ship.  This  class  of  ship  will  provide 
capabilities  never  before  available  to  the  RAN  and  will  allow  for  amphibious  operations  at 
scales  which  have  not  been  practised  by  the  RAN  for  generations.  Consequently,  the 
Australian  Defence  Force  (ADF)  personnel  joining  the  Canberra  class  of  ships  will  not 
have  prior  LHD  or  strong  amphibious  experience.  Operations  performed  from  an  LHD 
ship  will  require  it  to  be  manned  by  Navy,  Army  and  Air  force  personnel.  Activities  will 
often  require  interaction  between  ship  departments  and  those  departments  may  be 
manned  by  more  than  one  service. 

Ship  SOPs  should  be  used  by  the  ship's  crew  when  training  other  staff  and  as  a  reference 
for  themselves  during  an  activity.  They  are  also  useful  to  agencies  that  perform  testing  and 
evaluation  as  they  detail  the  steps  to  be  performed,  which  can  then  be  assessed.  During 
exercises  in  2013  RANTEAA  and  DST  Group  observed  that  majority  of  ship  personnel  do 
not  consult  the  ship  SOPs  before  performing  an  activity.  This  was  true  even  for  activities 
performed  infrequently  where  there  was  a  greater  risk  of  forgetting  some  aspect  of  the 
activity.  Anecdotally,  personnel  relied  on  word  of  mouth  and  what  they  remember  being 
taught  during  training.  SOPs  were  regarded  as  documents  that  must  be  written  to  satisfy 
quality  assurance  requirements;  they  were  not  regularly  used  as  reference  documents. 

DST  Group  noted  that  the  style  of  the  RAN  SOP  is  a  contributing  factor  to  these 
documents  not  being  used  regularly  as  references.  The  current  descriptive  styled 
documents  necessitate  users  to  read  the  whole  document  to  gain  a  full  understanding  of 
the  activity.  The  time  required  to  do  this  is  a  deterrent. 

For  these  reasons  modifications  were  recommended  to  the  format  of  RAN  SOPs  to  make 
them  documents  that  clearly  described  the  steps  to  be  performed  for  each  ship  activity  in 
an  easy  to  understand  and  implement  manner.  This  would  ensure  consistency  in  the  way 
activities  are  performed  and  enable  personnel,  such  as  those  newly  posted  to  the  LHDs,  to 
adopt  good  practice  and  quickly  become  proficient. 


2.2  Recommended  style 

The  RAN  creates  its  SOPs  using  computers  and  consequently  also  stores  and  accesses 
them  via  computer,  but  they  also  require  paper  copies  in  departments  where  access  to 
computers  is  limited.  Although  SOPs  could  be  produced  in  formats  other  than  documents, 
such  as  videos,  that  take  advantage  of  computer  technology,  written  documents  are  the 
simplest  to  produce  and  update.  Also,  if  only  a  refresh  is  required  it  is  quicker  to  read  than 
to  watch  a  video.  At  this  point  in  time  the  RAN's  preference  is  for  written  SOPs. 

A  recognised  and  recommended  method  for  clearly  presenting  the  steps  to  be  performed 
in  an  activity  in  an  easy  to  digest  written  form  is  to  use  flow  diagrams  [2-4],  Carefully 
recording  the  steps  of  an  activity  in  a  flow  diagram  encourages  the  writer  to  include  how 
information  is  obtained  and  passed  on;  how,  when  and  from  whom  approvals  are  sought; 
decision  steps  and  other  steps  that  would  be  missed  in  a  descriptive  only  SOP. 
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Importantly,  a  flow  diagram  on  its  own  is  not  sufficient.  To  ensure  flexibility  is  not  lost 
each  step  should  include  a  description,  requirements  and  guidance.  The  combination  of 
both  a  flow  diagram  and  supporting  information  provides  a  way  of  succinctly 
communicating  the  steps  of  an  activity  without  losing  the  flexibility  to  adapt.  As  personnel 
will  generally  avoid  reading  long,  wordy  documents,  particularly  when  pressed  for  time, 
the  flow  diagram  provides  a  succinct  and  easy  to  follow  process.  The  associated 
supporting  information  provides  the  background  detail  to  enable  experienced  personnel  to 
understand  the  reasoning  behind  each  step  so  that  an  informed  change  can  be  made  to  the 
process  if  circumstances  require  it. 


3.  Flow  diagram  support  tools 

Numerous  software  tools  support  drawing  a  flow  diagram  but,  as  described  in  Section  2.2, 
a  comprehensive  SOP  should  also  include  descriptions,  requirements  and  guidance.  The 
RAN  is  also  required  to  adhere  to  the  Defence  Records  Management  policy  [5],  which 
states  that  all  records  need  to  be  electronically  stored,  backed  up  and  changes  tracked. 
Software  tools  that  do  not  cover  all  of  these  capabilities  need  to  be  paired  with  other 
software  tools  to  create  a  complete  set  of  capabilities. 

For  this  study  only  the  tools  currently  available  to  the  RAN  were  reviewed.  Early  in  the 
review  it  was  found  that  the  RAN  had  access  to  suitable  software  tool  sets  and  there 
would  be  no  additional  value  gained  in  researching  other  software  tools.  The  software  tool 
review  considered  only  high  level  key  capabilities. 

Table  1  lists  the  software  tools  currently  available  to  the  RAN  and  the  high  level 
capabilities  of  each. 


Table  1  Softivare  tools,  and  their  capabilities,  available  to  the  RAN  for  producing  SOPs  based  on 
flow  diagrams 


Software 

name 

Flow 

diagram 

capability 

Flow  diagram 
drawing  level 

Information 
recording  capability 

Records 

management 

capability 

PowerPoint 

Yes 

Basic 

No.  Need  to  be 
paired  with  Word 

No.  Need  to  be 
paired  with 
Objective 

Word 

Yes 

Basic 

Yes 

No.  Need  to  be 
paired  with 
Objective 

Visio 

Yes 

High 

No.  Need  to  be 
paired  with  Word 

No.  Need  to  be 
paired  with 
Objective 

4TQ  Toolkit 

Yes 

High 

Yes 

Yes 
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In  Table  1: 

•  'Basic'  flow  diagram  drawing  level  means  shapes  can  be  drawn  with  lines  between 
them  but  additional  formatting,  relaying,  numbering  is  either  limited  or  requires 
significant  user  effort 

•  'High'  flow  diagram  drawing  level  means  shapes  are  automatically  linked  and 
formatting,  relaying  and  numbering  is  either  automatic  or  easily  performed  by  the 
user 

•  Objective  is  the  software  application  mandated  by  Defence  for  electronic  records 
management 

•  4TQ,  written  by  Axion,  is  a  suite  of  applications  that  assists  in  the  creation  of  SOPs 
and  the  management  of  the  associated  documentation.  SOPs  created  in  4TQ  are 
developed  via  flow  diagrams,  which  4TQ  can  then  convert  to  a  document.  The 
approval,  review  and  management  of  a  SOP  set  can  also  be  performed  within  4TQ. 
The  RAN  owns  a  large  number  of  4TQ  licences. 

Although  the  RAN  has  access  to  suitable  tools  for  creating  comprehensive  SOPs  no 
particular  tool  is  mandated,  nor  is  there  information  on  what  constitutes  a  good  quality 
SOP.  This  DST  Group  study  was  performed  to  develop  and  describe  a  methodology  for 
creating  good  quality  SOPs  based  on  flow  diagrams. 


4.  Creating  a  set  of  SOPs 

Rarely  will  one  SOP  be  sufficient  to  capture  the  steps  performed  for  an  area  of  work.  Due 
to  the  complexity  and  number  of  activities  performed  upon  a  ship  the  ship  set  of  SOPs  will 
contain  numerous  SOPs,  many  of  which  will  be  interconnected.  To  ensure  consistency 
across  the  set  of  SOPs  and  that  sufficient  resources  are  applied  to  their  production, 
development  and  publication  the  SOP  set  should  be  treated  as  a  project  and  managed 
accordingly.  Key  activities  include  scoping  the  set  of  SOPs,  creating  a  team,  developing  a 
plan,  writing,  reviewing  and  approving  procedures,  and  publishing  the  SOPs.  Maintaining 
a  SOP  set  also  requires  managing  the  set  and  keeping  an  audit  trail  of  any  changes  made. 


4.1  Scoping  a  set  of  SOPs 

Before  work  begins  the  scope  of  the  set  SOPs  should  be  defined.  It  is  important  to 
determine  the  activities  that  need  to  be  addressed  by  ship  SOPs  and  the  activities  that 
should  be  addressed  in  other  documents.  Ship  SOPs  should  address  activities  performed 
by  ship's  personnel  and  cover  steps  that  are  specific  to  the  ship.  Procedures  that  are  fully 
covered  in  ABRs  or  DEF(AUST)  5000  should  not  be  re-written  as  a  ship  SOP.  However, 
procedures  which  are  defined  in  ABRs,  etc.,  but  have  implementation  details  specific  to 
the  ship  should  be  included  in  the  list  of  SOPs. 

If  ah  ships  within  a  class  retain  the  same  system  and  equipment  fit  outs  then  the  SOP  is 
suitable  for  the  entire  class  of  ship.  However,  it  is  common  in  the  RAN  for  individual  ships 
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to  have  system  and  equipment  upgrades  at  different  times.  As  a  consequence  the  SOPs 
may  need  to  be  specific  to  a  particular  ship.  If  the  individual  ship  SOP  does  not  differ  from 
the  class  SOP  then  an  individual  ship  SOP  is  not  required. 

By  using  a  number  of  different  techniques  it  is  possible  to  develop  close  to  a  complete  list 
of  SOPs.  Different  techniques  will  examine  the  question  from  different  perspectives  and 
will  improve  insight  into  the  question.  Ideally  different  techniques  should  be  used  until  no 
new  information  is  obtained.  The  list  created  will  then  be  a  comprehensive  set  of  SOPs  that 
need  to  be  developed.  However,  the  list  of  sub-SOPs  will  develop  further  as  the  individual 
SOPs  are  drafted.  Some  of  the  useful  techniques  to  develop  a  list  of  SOPs  are 
brainstorming,  operational  scenario  walk-throughs,  historical  references  and  functional 
analysis. 

4.1.1  Brainstorming 

Brainstorming  is  a  technique  to  elicit  a  large  number  of  ideas  from  either  an  individual  or  a 
team.  It  usually  takes  the  form  of  a  question  being  posed  and  each  participant  noting  all  of 
their  answers.  Ideas  are  not  judged  but  are  collected  in  and  collated  into  themes.  The  aim 
is  to  collect  a  diverse  set  of  answers. 

The  advantages  of  this  method  are  all  team  members  have  an  equal  say  and  diverse  ideas 
can  be  expressed.  The  composition  of  the  group  needs  to  be  considered  to  reduce  the  risk 
that  like-minded  people  will  generate  similar  ideas. 

The  end  result  will  be  the  start  of  a  list  of  SOPs  that  need  to  be  written  to  cover  the  ship's 
activities. 

4.1.2  Operational  scenario  walk  throughs 

Operational  scenario  walk  throughs  involve  selecting  a  goal  you  wish  to  achieve  (a 
mission)  and  mentally  or  physically  walking  through  a  suitable  scenario  with  the  end 
point  as  the  desired  goal.  The  walk  through  can  be  done  by  a  small  team  or  by  an 
individual  followed  by  a  review  by  another  person.  The  Navy's  Mission  Essential  Task 
List  (METL)  [6]  is  one  set  of  suitable  goals  to  consider.  An  example  of  a  suitable  goal 
would  be  successfully  rescuing  a  person  who  has  fallen  over  the  side  of  the  ship  whilst  at 
sea  (Man  overboard). 

To  perform  an  operational  scenario  walk  through  use  the  goal  as  the  end  point  of  a 
scenario  and  walk  through  the  scenario  recording  the  activities  that  would  need  to  be 
performed  to  achieve  the  goal.  The  activities  should  be  broken  down  until  they  are 
performed  by  a  single  ship  department.  The  list  of  activities  contributes  to  the  list  of  SOPs 
to  be  written. 

It  is  important  for  each  department  to  also  consider  goals  and  scenarios  that  are  fully 
contained  within  their  department. 
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The  operational  scenario  walk-through  technique  is  useful  for  discovering  gaps  in  the  list 
of  SOPs.  It  also  highlights  sub-activities  that  are  commonly  performed.  A  disadvantage  is 
it  is  not  feasible  to  consider  every  possible  scenario  and  infrequent  activities  may  be 
missed. 

4.1.3  Historical  references 

SOPs  from  other  ship  classes,  coalition  partners  and  superseded  like-platforms  can  inform 
what  topics  need  to  be  addressed  in  SOPs.  These  existing  sets  of  SOPs  provide  example 
SOP  sets  and  can  be  used  to  determine  what  level  of  detail  should  be  contained  in  the 
written  SOPs.  They  also  provide  a  good  reference  for  how  an  activity  could  be  performed. 

It  is  important  to  be  aware  of  the  differences  between  Australia's  compliance  requirements 
and  those  of  other  countries  when  using  their  SOP  set  as  a  base.  Different  compliance 
requirements  may  impact  upon  the  set  of  SOPs  required.  The  RAN  is  also  likely  to  use  a 
different  crewing  configuration  that  may  affect  the  way  activities  are  performed. 
Consequently  SOPs  from  other  sources  cannot  be  taken  verbatim. 

4.1.4  Functional  analysis 

Functional  analysis  involves  breaking  down  a  high  level  activity  into  lower  level  activities 
in  a  hierarchical  manner.  Platforms,  for  which  capabilities  were  derived  during  acquisition 
using  the  Department  of  Defence  Architectural  Framework  [7],  or  similar,  may  already 
have  functional  analysis  diagrams,  in  the  form  of  the  Operational  View  5  diagrams.  These 
diagrams  can  be  used  to  determine  which  SOPs  should  be  developed.  If  not  the  Navy 
METL  [6]  could  be  used. 

A  high  level  activity  is  what  the  department  /  ship  is  responsible  for.  For  example,  from 
the  Navy  METL  (Amphibious),  Figure  1,  for  the  medical  department  the  high  level  activity 
is  'Provide  Health  Services'.  Two  of  the  lower  level  activities  required  to  achieve  this  high 
level  activity  are  'Perform  Triage  and  Casualty  Care'  and  'Operate  Primary  /  Secondary 
Casualty  Reception  Facility'.  The  lower  level  activities  become  the  titles  of  SOPs  to  be 
written. 

By  focussing  on  the  function  of  the  department/ ship,  activities  that  are  infrequent  and 
may  have  been  missed  in  the  operational  scenario  walk  through  will  be  discovered. 
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Figure  1  Functional  Hierarchy  excerpt  from  Navy  METL.  Tire  dashed  line  indicates  more  detail 
exists  in  the  Navy  METL. 

4.2  SOP  management  aspects 

To  ensure  the  SOPs  are  written  as  a  cohesive  set  it  is  important  to  determine  writing  and 
approval  responsibilities,  storage  methods  and  publishing  details  before  SOPs  are  written. 
This  information  should  be  recorded  and  stored  with  the  set  of  SOPs  to  ensure  consistency 
across  multiple  sub-sets  of  SOPs  that  may  be  brought  together  to  form  a  higher  level  set. 

The  key  aspects  to  consider  (listed  below)  are  addressed  in  the  following  sub-sections. 

1.  Manager  /  administrators 

2.  Author  /  Reviewer 

3.  Approver 

4.  SOP  review  interval 

5.  SOP  classification 

6.  SOP  template 

7.  SOP  distribution  format 

8.  Storage  location  of  electronic  SOP  files 

9.  Naming  and  numbering  convention 
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4.2.1  Manager  /  administrators 

A  person  or  team  of  personnel  need  to  be  assigned  as  the  managers  and  administrators  of 
the  SOP  set.  Their  role  will  be  to  collate  and  store  SOPs  from  different  departments  and 
check  the  naming  and  number  conventions  have  been  adhered  to.  They  will  also 
coordinate  the  review  process  and  check  that  the  definitive  set  contains  the  latest  versions 
of  the  SOPs.  This  role  may  also  be  responsible  for  forwarding  on  SOPs  for  final  approval 
and  sending  out  review  reminders. 

4.2.2  Author  /  reviewer 

SOPs  should  be  developed  by  personnel  who  have  the  experience  and  knowledge  for 
performing  the  activity.  This  will  most  commonly  be  the  personnel  performing  the  activity 
and  who  will  be  the  end  users  of  the  SOP  [8].  These  personnel  have  the  knowledge  and 
desire  to  develop  SOPs  that  cover  the  necessary  detail  in  a  usable  form. 

4.2.3  Approver 

The  developed  SOP  should  be  reviewed  by  experienced  personnel  who  were  not  involved 
in  the  development  of  the  SOP.  However,  the  role  assigned  to  approve  the  SOPs  should 
have  the  knowledge,  experience  and  authority  to  approve  work  processes. 

4.2.4  SOP  review  interval 

The  time  interval  between  SOP  reviews  is  influenced  by  two  main  factors,  the  stability  of 
the  SOP  and  the  risks  associated  with  performing  the  activity.  The  SOP  review  interval 
should  be  set  to  the  longest  period  for  which  the  risks  and  the  steps  to  be  performed  for 
the  activity  are  unlikely  to  change. 

If  the  risks  associated  to  the  steps  performed  for  an  activity  are  high  more  regular  reviews 
are  warranted.  Also,  if  the  cause  of  the  risk  may  change  over  time  the  level  of  risk  should 
be  reviewed,  e.g.  levels  of  contaminant  in  an  area  fluctuate  changing  the  risk  to  personnel 
working  in  the  area. 

Reviews  should  also  be  performed  when  a  significant  change  or  incident  occurs  that  may 
impact  upon  how  activities  are  to  be  performed;  for  examples,  a  change  in  command 
personnel  results  in  different  reporting  or  approval  requirements,  or  there  is  a  change  to  a 
higher  level  ABR  that  needs  to  be  adhered  to,  or  an  injury  or  death  occurs  placing  the 
activity  process  into  question.  In  these  cases  affected  SOPs  should  be  reviewed. 

It  is  important  to  ensure  SOPs  maintain  their  effectiveness  in  detailing  appropriate  safe 
work  practices  based  on  current  best  knowledge.  Consequently,  an  interval  of  no  more 
than  12  months  is  recommended  as  it  ensures  SOPs  do  not  become  so  outdated  that  a  full 
rewrite  is  required  rather  than  just  an  update. 
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4.2.5  SOP  classification 

The  classification  of  the  SOPs  should  be  in  line  with  Defence  Security  Manual  [9] 
requirements. 

4.2.6  SOP  template 

To  ensure  consistency  across  the  set  of  the  SOPs  and  that  an  appropriate  level  of  detail  is 
included  in  each  SOP  a  template  should  be  used.  The  template  can  be  imbedded  with  the 
tool  used  to  capture  the  SOP  or  be  a  set  of  written  instructions. 

4.2.7  SOP  distribution  format 

SOPs  are  living  documents  that  should  be  referred  to  and  amended  to  reflect  changes  in 
practice.  Personnel  who  perform  activities  regularly  will  remember  the  steps  involved  and 
will  generally  not  need  to  refer  to  a  SOP  unless  they  are  training  others.  However,  if  an 
activity  is  performed  infrequently  the  steps  to  be  performed  are  likely  to  be  forgotten  and 
the  SOP  will  need  to  be  referred  to.  Consequently,  the  SOP  documents  need  to  be  readily 
available  to  their  users. 

The  SOPs  will  be  created  electronically  but  this  may  not  be  the  best  final  format  for  users. 
Different  departments  may  have  different  requirements  and  this  should  be  taken  into 
account  when  distributing  and  determining  where  SOPs  are  to  be  stored  for  use.  If  SOPs 
are  printed  it  is  important  to  ensure  old  versions  are  replaced  by  current  versions  as  soon 
as  versions  change. 

4.2.8  Storage  location  of  electronic  SOP  files 

The  finalised  SOP  set  should  be  stored  electronically  in  an  area  that  is  accessible  to  all  SOP 
users  but  be  controlled  to  ensure  only  the  latest  approved  versions  are  available.  Normally 
only  the  administrators  of  the  SOP  set  would  have  write  access  to  the  SOP  set  location. 

4.2.9  Naming  and  numbering  convention 

The  final  set  of  SOPs  is  likely  to  be  formed  from  a  number  of  sub-sets  from  numerous 
departments.  By  using  a  consistent  numbering  and  naming  system  the  sub-sets  can  easily 
be  aggregated  to  form  a  larger  set. 

A  simple  method  to  avoid  re-use  of  numbers  is  to  allocate  a  number  to  each  department. 
Each  department  then  uses  this  number  followed  by  a  '-'  followed  by  the  department's 
SOP  number.  In  the  example  in  Table  2  and  Table  3  the  Mechanical  Engineering  (ME) 
Department  has  been  allocated  the  number  4.  The  Man  Overboard  SOP  has  been  assigned 
the  'SOP  number'  of  5. 

A  version  number  should  also  be  included  in  the  SOP  file  name,  so  that  it  is  clear  which 
SOP  is  the  latest  version.  A  date  can  be  used  in  the  file  name  to  perform  the  role  of  a 
version  number. 
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4.3  RAN  SOP  management 

Table  2  contains  a  suggested  implementation  of  the  aspects  described  in  section  4.2  for  the 
RAN  ship  Canberra.  It  is  the  first  ship  in  the  RAN  to  use  the  flow  diagram  methodology  for 
documenting  its  SOPs,  although  the  aim  is  to  extend  the  use  across  the  fleet. 

The  tool  recommended  to  Canberra  for  developing  their  SOPs  was  4TQ  because  it  provides 
all  of  the  key  high  level  capabilities  required  to  produce  a  comprehensive  SOP  based  on  a 
flow  diagram. 


Table  2  Suggested  RAN  ship  SOP  management  allocations 


Aspect 

Allocation 

Ship  SOP  manager 

Executive  Officer 

Ship  SOP  approver 

Commanding  Officer 

Ship  SOP  review  interval 

Yearly 

Department  SOP  manager 

Department  Head 

Department  SOP  approver 

Executive  Officer 

Department  SOP  review 
interval 

Yearly 

Classification  of  SOPs 

FOR  OFFICIAL  USE  ONLY  (FOUO) 

SOP  development  tool 

4TQ  Toolkit  (RAN) 

Performer's  list 

As  per  Ship's  Watch  and  Station  bill 

4TQ  file  name  convention 

CANB  SOP  SOP-number  department  name-of-SOP 
ddmmmyyyy 

Objective  name  convention 

HMAS  Canberra  SOP  SOP-number  department  name-of-SOP 
dd  mmm  yyyyy 

The  file  name  convention  used  in  Table  2  follows  the  2013  Information  Management 
HMAS  Canberra  Work  Instruction.  Table  3  expands  the  details  used  in  the  construction  of 
the  file  name. 


Table  3  Explanation  of  fields  in  SOP  file  name 


Field 

Explanation 

Example  value 

SOP  number 

SOP  number 

4-5 

department 

department  acronym 

ME 

name  of  SOP 

name  of  SOP 

Man  Overboard 

dd 

two  digit  day 

28 

mmm 

three  letter  month 

Mar 

yyyy 

four  digit  year 

2013 

Example  Objective  file  name: 

HMAS  Canberra  SOP  4-5  ME  Man  Overboard  28  Mar  2013 
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The  filename  convention  for  4TQ  is  different  to  Objective  because  4TQ  imposes  the 
following  file  name  restrictions: 

1.  File  path  names  and  file  names  must  be  less  than  255  characters 

2.  If  distributing  by  compact  disk  the  maximum  depth  of  folders  is  seven  (7) 

3.  The  number  of  items  (maps,  documents  and  forms)  within  a  Category  should  be 
less  than  forty  (40) 

Therefore,  the  equivalent  4TQ  file  name  becomes: 

CANB  SOP  4-5  ME  Man  Overboard  28Mar2013 


5.  Developing  SOPs 

The  aim  of  a  ship  SOP  is  to  communicate  to  the  reader  in  sufficient  detail  a  description  of 
the  steps  that  should  be  performed  for  a  particular  activity  on  that  particular  ship.  The 
RAN  ABRs  provide  the  rules  and  safety  requirements  across  all  ships  or  for  a  particular 
class  of  ship.  The  information  in  the  ABRs  and  DEF(AUST)  5000  should  be  used  to  develop 
the  procedure  to  follow  on  the  ship.  Eligher  level  doctrine  should  also  be  referred  to. 

At  the  beginning  of  a  SOP  document  there  should  be  a  clear  description  of  the  activity  aim, 
scope  and  where/when  the  procedure  is  applicable/ not  applicable.  For  clarity  and  ease  of 
use  a  SOP  should  then  include  a  flow  diagram  clearly  showing  the  steps  to  be  performed 
for  the  activity.  Following  the  flow  diagram  there  should  be  a  description  of  each  step  in 
the  procedure  that  includes  any  conditions,  such  as  safety,  security  or  resource 
requirements.  As  a  whole  the  SOP  document  should  be  usable  to  both  personnel  requiring 
a  quick  refresh  and  to  personnel  requiring  explanations  of  each  step  so  that  changes  to  the 
process  can  be  informed.  Appendix  C  contains  an  example  SOP  developed  using  the 
method  described  in  this  section. 


5.1  SOP  scope  and  bounds 

The  first  steps  in  writing  an  SOP  are  to  bound  the  SOP,  to  clearly  define  what  activity  is 
being  described,  under  what  conditions  and  for  whom  the  SOP  is  intended.  Considering 
the  scope  of  the  SOP  before  writing  it  enables  the  author  to  have  a  clear  idea  of  what  to 
cover  in  the  SOP.  It  also  reduces  the  chances  of  overlap  with  other  SOPs  and  highlights 
when  additional  SOPs  are  required.  Considering  the  audience  encourages  the  use  of 
appropriate  language. 
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The  bounds  and  scope  of  the  SOP  should  be  recorded  at  the  beginning  of  the  SOP 
document.3.  The  aspects  to  include  are: 

1.  SOP  objective 

2.  Start  State 

3.  End  State 

4.  Assumed  Ship  Readiness  State 

5.  Assumed  Environmental  Conditions 

6.  Target  Audience 

7.  Assumed  Background  Knowledge 

8.  Authoritative  /  Informative  Sources 

9.  References 

In  the  following  sub-sections  the  example  of  transferring  goods,  excluding  explosive 
ordinance,  onto  a  ship  whilst  it  is  in  port  has  been  used.  The  examples  are  in  italics. 

5.1.1  SOP  objective 

The  SOP  objective  is  the  end  point  the  activity  is  trying  to  achieve  and  provides  the  reader 
a  means  of  identifying  if  the  SOP  is  relevant  to  their  desired  purpose. 

Wlren  the  ship  is  in  port  safely  transfer  goods,  excluding  explosive  ordinance,  from  the 
delivery  vehicle  on  the  wharf  to  the  designated  ship  store  area.  Explosive  ordinance 
transfers  are  covered  in  a  separate  SOP. 

5.1.2  Start  State 

The  Start  State  entry  clearly  articulates  all  the  preparations,  if  any,  that  have  occurred  and 
are  not  included  in  this  SOP.  If  possible  any  preparatory  SOPs  should  be  identified. 

This  SOP  assumes  that  the  recognition  of  the  need  for  stores,  the  ordering  and  the 
arrangement  of  delivery  have  already  occurred  and  are  captured  in  separate  SOPs. 

This  SOP  begins  when  the  delivery  vehicle  arrives  alongside  the  ship. 

5.1.3  End  State 

The  End  State  entry  clearly  states  the  end  goal  of  the  activity,  which  is  where  the  SOP 
ends. 


Delivered  stores  stowed  and  receipted. 


3  In  4TQ  each  aspect  should  be  entered  as  a  heading  under  Title  page/Process  Summary  and  an 
entry  made  under  each  heading. 
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5.1.4  Assumed  Ship  Readiness  State 

The  Ship  Readiness  State  describes  in  which  ship  readiness  states  this  SOP  can  be 
performed.  If  more  than  one  ship  readiness  state  applies  to  the  SOP  all  relevant  states 
should  be  listed.  If  all  ship  readiness  states  are  relevant  enter  'All  ship  readiness  states'. 
This  is  preferable  to  a  blank  entry  as  it  shows  that  this  aspect  has  been  considered. 

Ship  alongside  the  wharf. 

5.1.5  Assumed  Environmental  Conditions 

The  Environmental  condition  is  the  environment  (weather)  the  SOP  can  be  safely 
performed  in,  e.g.:  'Sea  States  less  than  4'  or  'Wind  Speeds  below  30  knots'.  If  the  SOP 
applies  to  all  environmental  conditions  enter  'All  environmental  conditions.' 

All  environmental  conditions. 

5.1.6  Target  Audience 

The  personnel/ group  this  SOP  has  been  written  for  is  entered  here.  It  may  be  particular 
individual  roles,  teams  or  more  than  one  team.  The  language  used  in  the  SOP  should  be 
tailored  to  the  personnel  who  are  expected  to  read  and  use  the  SOP. 

SOP  USERS 

LOG  department 
AMPHIB  department 

FOR  INFO  ONLY 

Embarked  Forces  Logistics  Element 

5.1.7  Assumed  Background  Knowledge 

The  expected  knowledge  base  of  the  personnel  using  the  SOP  should  be  recorded  and  will 
determine  the  appropriate  level  of  technical  jargon  that  can  be  used  in  the  SOP.  If 
personnel  are  expected  to  have  completed  particular  training  before  performing  the 
activity  described  in  the  SOP  the  technical  terms  used  in  the  training  can  be  used  in  the 
SOP  without  explanation.  If  the  SOP  is  to  be  used  by  non-trained  personnel  any  technical 
terms  should  be  explained. 

Qualified  Terminal  Operators 
Qualified  Logistics  Operators 

5.1.8  Authoritative  /  Informative  Sources 

This  entry  provides  the  opportunity  to  note  any  knowledge  from  external  personnel  or 
experience  external  to  the  ADF  that  were  drawn  upon  to  develop  this  SOP,  such  as 
suggestions  from  personnel  posted  from  overseas  or  experience  from  overseas  training 
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courses  or  exercises.  This  is  useful  background  information  to  the  crew  who  follow  on  and 
update  the  SOP.  It  enables  them  to  understand  how  the  process  was  initially  developed 
and  the  background  behind  some  of  the  decisions. 

This  is  particularly  important  for  vessels  such  as  Canberra,  which  are  the  first  in  their  class 
to  come  into  service.  Procedures  for  these  vessels  cannot  mirror  the  procedures  used  on 
other  classes  of  vessels  due  to  the  ship's  differences.  Procedures  will  need  to  be  developed 
based  on  experience  and  advice  from  many  sources. 

A  NIL  entry  is  acceptable. 

NIL 

5.1.9  References 

The  documents,  or  section  of  documents,  to  which  this  whole  SOP  refers  to  and  should 
comply  with  should  be  recorded.  References  related  to  only  an  individual  step  should  be 
recorded  within  that  step's  description  rather  than  with  the  SOP  summary  information. 

Navantia  LHD  Amphibious  Deployment  and  Sustainment  Capability 

OPS-1-3-  Cargo  Embarkment  and  Disembarkment  Report,  Document  No  835-6-35— 

3  8- OR 

AFGOs  Chapt 

ABR  5562  -  Pending  change 

ABR  862  Vo2 

5.2  Creating  a  flow  diagram 

A  flow  diagram  uses  symbols  and  lines  to  graphically  represent  the  order  and  flow  of 
tasks  within  a  procedure.  The  flow  from  one  task  to  another  is  clearly  represented  and 
decisions  and  alternate  paths  are  also  easy  to  discern.  The  end  result  is  a  diagram  that 
clearly  shows  the  process  to  follow.  The  user  is  not  required  to  read  a  lengthy  document  or 
interpret  the  required  steps  to  perform  the  activity. 

Object  Management  Group's  (OMG)  Business  Process  Model  and  Notation  (BPMN)  [10]  is 
becoming  the  standard  to  use  when  modelling  a  business  process  using  a  computer.  These 
models  take  the  form  of  a  flow  diagram  but  include  greater  detail  to  enable  computer 
simulation  of  the  model.  The  notation  includes  a  large  number  of  variations  on  each 
symbol,  each  with  a  specific  meaning  in  simulation.  On  an  SOP  flow  diagram  this  level  of 
detail  is  not  required  because  it  is  not  designed  to  be  computer  simulated;  the  basic  shapes 
of  the  notation  symbols  are  sufficient.  Appendix  B  show  the  basic  notational  shapes  used 
in  4TQ. 

To  create  a  flow  diagram,  mentally  or  preferably  physically  walk  through  the  activity  and 
record,  using  the  specified  symbol  set,  the  flow  of  steps  to  be  performed.  The  flow  should 
start  with  a  trigger  and  each  step  should  be  a  unique  action.  It  should  end  with  the  desired 
end  goal. 
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To  maintain  comprehensibility  of  the  final  product  a  balance  should  be  sought  between 
documenting  detail  and  the  size  and  complexity  of  the  SOP.  The  flow  should  contain  the 
key  steps  a  person  with  the  specified  knowledge  background  would  need  to  be  told  to  be 
able  to  perform  the  activity  for  the  first  time. 

The  following  sub-sections  provide  further  guidance  when  using  flow  diagrams  to  create  a 
SOP. 

5.2.1  Effective  language 

A  clear  and  succinct  SOP  uses  effective  language  in  both  the  flow  diagram  and  the 
background  description  of  the  steps.  Effective  language  is  tailored  to  the  audience,  taking 
their  experience  and  training  into  account,  and  does  not  assume  acronyms  and 
abbreviations  are  understood. 

Effective  language  tips  for  SOPs  are: 

•  Each  step  should  be  an  action. 

•  Be  succinct  (short  clear  sentences). 

•  Use  short  words  and  minimise  the  word  count. 

•  Be  clear. 

•  Be  imperative  (like  a  command). 

•  Write  steps  in  present  tense. 

•  Avoid  ambiguity. 

•  Do  not  include  slang. 

•  Be  consistent  with  terms. 

•  Use  acronyms  in  the  step  title  but  expand  acronyms  in  the  step  description. 

•  Include  a  glossary  /  acronyms  list. 

•  Do  not  include  unnecessary  components  (e.g.:  cartoons,  anecdotes,  quotations). 
Table  4  contains  examples  of  ineffective  and  effective  language  for  SOP  flow  diagrams. 


Table  4  Examples  of  ineffective  and  effective  flow  diagram  language 


Ineffective  language  in  flow 
diagrams 

Issue 

Effective  language  in  flow 
diagrams 

The  engine  is  to  be  turned 
off. 

Not  imperative. 

Turn  off  the  engine. 

The  canisters  and  associated 
FDDRs  are  to  be  returned  to 
the  CCO  for  checking. 

Not  concise. 

Return  canisters  and  FDDRs  to 
CCO. 
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Ineffective  language  in  flow 
diagrams 

Issue 

Effective  language  in  flow 
diagrams 

Evacuate  the  compartment 
shutting  all  doors  and 
hatches  then  make  your  way 
to  the  Damage  Control  Deck 
clearing  any  adjacent 
compartment  of  personnel. 

More  than  one 
action. 

1.  Evacuate  compartment, 
shutting  all  doors  and  hatches. 

2.  Check  and  clear  adjacent 
compartments  of  personnel. 

3.  Move  to  the  Damage  Control 
deck. 

In  this  particular  case  listen 
to  the  pipe  as  you  may  be 
instructed  to  muster  at  a 
location  other  than  your 
usual  station. 

Not  concise. 

More  than  one 
action. 

1.  Listen  to  pipe. 

2.  Muster  at  instructed  location. 

Don  personal  protective 
equipment  as  per  compliance 
document  xxxx. 

Requires  the  user 
to  look  up  another 
document. 

Put  on  full  hearing  protection 
and  safety  glasses. 

5.2.2  Considerations 

At  each  step  of  the  flow  a  range  of  aspects  should  be  considered  to  ensure  all  important 
information  is  recorded.  Majority  of  this  information  is  not  required  on  the  flow  diagram 
but  should  be  recorded,  where  appropriate,  in  the  description  sections  of  the  SOP 
document. 

The  key  aspects  to  consider,  listed  below,  are  covered  in  the  following  sub-sections: 

•  Safety 

•  References 

•  Security 

•  Information  input  and  output 

•  Physical  location 

•  Physical  constraints 

•  Approval  requirements 

•  Performer 

•  Resources  required 

5.2.2.1  Safety 

The  RAN  records  identified  risks  and  associated  mitigations  in  Safety  Risk  Profiles  (SRP). 
The  process  described  in  a  SOP  must  comply  with  the  relevant  SRPs  and  any  associated 
safety  steps  should  be  included  in  the  process.  Any  SRPs  referred  to  should  be  recorded  as 
a  reference. 

52.2.2  References 

Any  document  containing  information  that  must  be  adhered  to  should  be  recorded  with 
the  SOP.  References  relevant  to  the  entire  SOP  should  be  recorded  on  a  summary  page  at 
the  beginning  of  the  SOP.  References  relevant  to  only  a  particular  step  should  be  recorded 
with  the  description  of  the  step. 
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5.2.23  Security 

The  security  requirements  of  a  step  should  be  considered.  The  requirements  may  be 
physical  or  data  related.  Additional  steps  may  need  to  be  performed  to  ensure  compliance 
with  security  requirements.  If  a  security  document  is  referenced  it  should  be  recorded  as  a 
reference  for  the  step. 

5.2.2A  Information  input  and  output 

A  process  often  involves  the  use  and  passage  of  information.  The  requirement  to  obtain, 
store  or  pass  on  information  should  be  included  in  the  process,  either  as  a  specific  step  or 
in  the  description  of  a  step.  The  system  used  or  the  roles  from  whom  information  is 
obtained/ passed  should  also  be  recorded. 

5. 2. 2.5  Physical  location 

If  a  step  must  be  performed  in  a  particular  location  this  should  be  recorded  with  the  step. 
The  location  identifier  must  be  an  approved  identifier  and  recognised  by  all  ship's 
personnel. 

5. 2. 2. 6  Physical  constraints 

If  a  step  is  performed  in  a  particular  physical  location  physical  constraints  should  be 
considered.  Additional  steps  may  be  required  to  ensure  the  step  can  be  performed  safely 
in  the  specified  location. 

5.2.2. 7  Approval  Requirements 

The  requirement  for  approval  should  be  included  in  the  process.  Depending  upon  the 
frequency  of  the  need  for  approval  it  may  be  included  as  a  specific  step  or  within  the 
description  of  a  step.  A  balance  needs  to  be  achieved  between  having  sufficient  detail  in 
the  flow  diagram  and  having  too  much  detail  leading  to  the  flow  diagram  being 
unreadable. 

5. 2. 2. 8  Performer 

The  role  responsible  for  performing  the  step  should  be  recorded  with  the  step  and  the 
name  of  the  role  should  be  understood  by  all  ship's  personnel.  The  ship's  watch  and 
station  bill  contains  a  list  of  ship's  roles  and  the  performer  should  be  selected  from  this  list 
if  possible. 

If  the  performer  is  a  team  the  composition  of  the  team  should  be  described  in  the  SOP, 
either  as  a  definition  or  in  the  description  of  a  step. 

5. 2. 2. 9  Resources  required 

The  resources,  such  as  equipment,  communication  systems,  software  tools  etc.  required  to 
perform  the  step  should  be  recorded  in  the  description  of  the  step.  This  is  important 
information  for  the  person  who  will  perform  the  step  and  can  also  be  used  to  justify  the 
need  for  particular  resources. 
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5.2.3  What  to  include  /  not  include 

Just  as  important  as  what  to  include  is  what  not  to  include.  Although  not  a  complete  set 
recommendations  are: 

Assumptions,  such  as  the  person  reading  the  SOP  will  already  know  they  have  to  report  to  their 
supervisor,  must  be  avoided.  It  is  better  to  include  the  report  to  the  supervisor  as  a  step 
than  risk  the  action  being  missed  by  someone  new  to  the  position  who  has  not  been  given 
a  full  hand-over. 

The  flow  should  show  the  expected  normal  set  of  actions.  There  will  be  exceptions  to  this 
norm  but  unless  the  exception  occurs  frequently  it  should  be  covered  in  the  description  or 
in  a  separate  SOP  rather  than  as  a  separate  branch  in  the  flow.  The  aim  is  to  create  an  easy 
to  follow  diagram  of  the  normal  set  of  actions.  If  many  exceptions  are  included  the 
diagram  will  become  difficult  to  use. 

The  name  of  a  performer  should  be  the  role  name  rather  than  the  specific  individual  who 
is  currently  posted  into  the  position. 

Requiring  the  user  to  read  a  reference  when  performing  the  activity  should  be  avoided. 
Instead  the  relevant  details  from  the  reference  should  be  included  in  the  SOP. 

Each  step  should  be  performed  by  one  performer  (can  be  a  team).  If  the  step  triggers 
simultaneous  actions  by  another  performer  these  actions  should  be  recorded  in  a  separate 
branch,  rather  than  left  out. 

5.2.4  Cyclic  activities 

Flow  diagrams  traditionally  show  sequential  flows;  however  cyclic  flows  can  also  be 
represented.  In  a  cyclic  flow  the  start  or  a  step  is  triggered  by  the  completion  of  the  flow  or 
another  step.  The  cycle  may  be  the  entire  flow  or  a  portion  of  the  flow.  An  example  is  a 
repair  cycle. 

Before  a  repair  is  done  a  test  is  performed  to  determine  what  repair  is  required.  Once  the 
repair  is  complete  the  test  will  be  redone  to  check  the  equipment  is  fully  functional.  If  not 
fully  functional  then  another  repair  /  test  process  will  be  performed.  If  the  equipment  is 
working  the  repair  cycle  ends.  Figure  2  shows  this  graphically. 
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Figure  2  Flow  diagram  of  the  cyclic  repair  flow 
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As  cyclic  activities  are  repetitive  it  can  be  difficult  to  determine  the  trigger.  The  trigger  is 
usually  a  state  that  needs  to  be  resolved,  e.g.  equipment  is  not  working,  stores  are  required 
or  a  patient  is  in  sick  bay.  All  cyclic  flows  should  have  an  end  condition  that  stops  the 
cycle.  This  is  usually  the  opposite  of  the  trigger  state. 

5.2.5  Activities  triggered  by  a  timetable 

Many  ship  activities  will  be  triggered  by  the  time/ day  or  a  after  a  period  of  time  has 
elapsed.  The  trigger  for  these  activities  is  the  specified  time/ day  or  a  period  of  time,  e.g. 
1500  Mondays,  3rd  Tuesday  of  the  month,  or  30  days  after  last  meeting. 

If  using  a  specific  date  be  aware  the  day  of  the  week  will  be  different  each  time  the  activity 
is  performed. 

5.2.6  Pictures  /  video 

Flow  diagrams  can  be  enhanced  with  the  use  of  pictures.  Pictures  are  useful  for  showing 
the  state  of  a  piece  of  equipment  or  what  it  looks  like.  If  possible  the  picture  can  be  placed 
on  the  flow  diagram.  If  the  tool  being  used  to  create  the  flow  diagram  does  not  allow  this 
then  the  picture  will  need  to  be  added  to  the  description  section  of  the  created  document.4 

If  it  is  difficult  to  describe  a  process  or  part  of  a  process  using  words  or  a  flow  diagram  a 
video  could  be  used.  A  hyperlink  to  a  video  of  the  process  to  follow  could  be  added  to  the 
flow  diagram  or  the  description  section  of  the  SOP  document,  if  the  tool  to  create  the  flow 
diagram  supports  this.  Keep  in  mind  that  videos  will  only  be  available  electronically  and 
consequently  are  not  suited  to  cases  where  the  SOP  is  required  in  departments  with 
limited  computer  access.  Also,  that  generally  it  takes  longer  to  watch  a  video  than  to  read 
or  follow  a  flow  diagram.  Consequently  video  should  be  limited  to  processes  that  are 
difficult  to  describe  in  words  or  flow  diagrams. 


6.  Future  work 


This  study's  scope  was  limited  to  the  RAN's  current  capability,  which  limits  crews'  access 
to  technology  to  obtain  references  when  performing  their  activities.  In  the  future  crews 
may  have  much  greater  access  to  technology,  whether  in  the  form  of  desk  top  computers 
or  mobile  electronics,  such  as  phones  or  tablets.  When  this  occurs  it  would  be  worth 
revisiting  how  best  to  capture  and  communicate  operating  procedures.  Access  to 
technology  will  open  up  the  options  available  for  communicating  operating  procedures. 
Research  on  different  communication  techniques,  such  as  interactive  flow  diagrams  and 
videos  should  be  considered  in  the  future. 


4  Pictures  other  than  small  icons  cannot  be  added  to  flow  diagrams  created  in  4TQ.  They  must  be 
added  to  the  final  document  created  by  4TQ,  noting  that  any  change  made  to  the  flow  in  4TQ  will 
result  in  a  new  document  to  which  the  picture  will  have  to  be  added  again. 
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7.  Summary 

The  RAN  has  in  the  past  written  its  ship  SOPs  as  descriptive  rules.  With  the  introduction 
of  the  new  LHD  it  has  been  recognised  this  SOP  format  will  not  be  sufficient  to  enable  new 
crews  to  quickly  become  proficient  in  their  new  roles  or  for  RANTEAA  to  assess  their 
capability.  To  resolve  these  issues  DST  Group  was  requested  to  develop  a  methodology  for 
creating  SOPs  using  flow  diagrams  and  to  pilot  it  with  the  crew  of  the  first  LHD,  HMAS 
Canberra. 

This  report  discussed  the  issues  and  provided  the  details  of  the  method  tailored  to  the 
RAN  for  developing  SOPs  using  flow  diagrams.  It  covered  the  need  for  a  flow  diagram, 
effective  language  and  comprehensive  supporting  descriptions  of  each  step. 
COMSURFOR,  supported  by  RANTEAA,  plans  to  adopt  this  new  way  of  developing  SOPs 
by  directing  its  use  across  the  fleet. 
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Appendix  A:  Example  of  current  RAN  SOP 

This  is  an  excerpt  from  a  RAN  ship  SOP  written  in  2011  covering  what  to  do  if  a  crew 
member  is  discovered  missing.  It  is  a  mixture  of  steps  to  perform  and  items  to  consider. 
The  role  responsible  for  each  step  is  not  always  stated  and  the  order  in  which  the  steps 
should  be  performed  is  not  necessarily  the  order  as  written. 


PROCEDURES  WHEN  A  CREW  MEMBER  IS  DISCOVERED  MISSING 


1.  In  all  cases  where  a  man  overboard  has  not  been  witnessed  but  is  suspected,  the 
following  action  is  to  be  taken: 

2.  An  immediate  check  of  the  person's  cabin  and  mess  room  is  to  be  made  along  with 
a  general  pipe  for  that  person  to  contact  the  bridge. 

3.  The  OOW  should  IMMEDIATELY  notify  the  CO. 

4.  The  ship,  if  underway,  is  to  be  turned  to  commence  its  track.  The  ship  should  alert 
other  ships  in  the  vicinity  if  this  involves  manoeuvring  in  close  proximity  or  in  the 
vicinity  of  a  traffic  separation  scheme.  If  ICW  other  units,  the  OTC  is  to  be 
informed  and  may  take  charge  of  the  SAR  incident. 

5.  The  ship  is  to  be  brought  to  Modified  Leaving  Ship  Stations  in  order  that  a 
comprehensive  muster  can  be  made.  If  other  service  personnel  are  embarked  then 
they  must  also  be  comprehensively  mustered. 

6.  If  someone  is  reported  missing  at  the  muster  a  whole  ship  search  (OP  THIMBLE) 
should  be  undertaken  in  addition  to  a  sea  search  to  establish  that  the  missing 
person  is  not  on  board  incapacitated. 

7.  The  Commanding  Officer,  the  missing  persons  Head  of  Department,  the  Chief 
Officer  and  Navigator  should  meet  to  determine  when  the  man  was  last  seen. 

8.  The  Navigator  will  establish  the  ship's  position  at  the  time  he  / she  was  last  seen, 
which  then  becomes  the  starting  point  for  a  search  pattern. 

9.  The  Ship  steams  back  down  its  track,  engines  ready  for  immediate  manoeuvring.  If 
the  man  is  sighted,  procedures  set  forth  in  para  12  are  put  into  motion.  A  SAR 
helicopter  (if  available)  should  be  launched  at  the  earliest  opportunity  consistent 
with  flight  safety. 

10.  If  the  missing  person  is  not  sighted  by  the  time  it  reaches  the  last  known  position 
the  person  was  seen,  a  search  pattern  is  established  based  on  predicted  set  and  drift 
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of  the  person  in  the  water.  Close  attention  must  be  paid  to  possible  current  and 
tidal  flows  because  these  will  affect  the  persons  drift  far  more  than  wind. 

11.  If  in  coastal  waters,  assistance  from  shore  or  air  assets  should  be  requested.  If  in 
open  Ocean,  the  assistance  of  any  other  ships  in  the  vicinity  should  be  requested.  If 
in  company  with  other  ships  with  embarked  helicopters,  use  of  their  helicopters 
should  be  requested. 

12.  Anyone  seeing  a  man  fall  overboard  is  to  Shout 

"MAN  OVERBOARD  PORT/STARBOARD" 

13.  Throw  the  nearest  lifebuoy,  if  possible,  the  flare  attached  type.  Avoiding  hitting 
the  man  in  the  water. 

14.  Inform  the  bridge  by  the  quickest  possible  method  ensuring  that  no-one  loses 
sight  of  the  man  overboard.  If  a  telephone  is  used,  standby  the  telephone  in  case  of 
any  further  information  is  required.  Emergency  Telephone  Number  999 

15.  Keep  the  man  in  sight  for  as  long  as  possible. 

16.  The  OOW  is  to: 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  n 

SOUND  GENERAL  ALARM 

1 1 1 1 1 1  ■ 1 1 1 ■ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  ■■ 

a.  BROADCAST: 

"MAN  OVER  BOARD  X  3 
MAN  OVERBOARD  PORT/STBDSIDE 
STAND  BY  TO  RECOVER  PORT/STBD  SEABOAT" 

b.  Release  Life  Buoys. 

c.  Mark  the  plot,  ECDIS,  GPS,  Radar,  Ops  Room. 

d.  Manoeuvre  ship. 

e.  DGs  at  min  3  sets  to  run 

f.  Hoist  Flag  O. 

g.  Sound  3  Long  blasts. 

h.  AWAY  SEABOAT  A.S.A.P. 

i.  Medics  to  sick  bay. 

j.  Person  reporting  MOB  to  contact  bridge  (if  possible). 

k.  Prepare  PAN  PAN  or  MAYDAY  message. 

l.  Post  Extra  Lookouts. 

Extra  Lookouts 


17.  2  Extra  Lookouts  will  be  nominated  by  WOD  if  required. 
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18.  The  lookouts  are  to  report  immediately  to  the  bridge  and  commence  looking  for 
the  MOB. 

19.  They  are  to  be  shown  where  to  look  by  the  OOW  or  a  suitable  person. 

20.  On  seeing  the  MOB  they  are  to  shout  for  attention  and  point  at  the  MOB  whilst 
NEVER  breaking  view  of  the  MOB. 

21.  They  are  to  continue  pointing  until  the  FRC  has  recovered  the  MOB. 

22.  The  Extra  Lookouts  are  only  to  be  stood  down  by  the  OOW. 
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Appendix  B:  4TQ  flow  diagram  symbols 


The  symbols  used  by  4TQ  are  shown  in  Table  5.  They  follow  the  notational  concepts 
within  OMG's  BPMN.  The  number  above  each  symbol  is  unique  to  4TQ  and  is  used  to 
connect  the  flow  diagram  steps  to  their  descriptions,  which  are  recorded  later  in  an  SOP 
document.  The  splitter  symbol  is  also  unique. 


Table  5  Symbols  used  in  4TQ  to  represent  the  different  steps  involved 


Name 

Step  description 

Symbol 

Start 

The  trigger  of  the  process.  This  may  be  an  event  or  a  set 
time/ date. 

0 

r  " 

Trigger  Occurs 

V 

Test 

A  decision  that  can  only  result  in  "Yes"  or  "No" 

2  JL 

s'  \Yes 

<T  Decide  ?  — 

|No 

Task 

A  step  that  must  be  performed. 

1  1 

Perform 

Action 

1 

Splitter 

Used  when  there  is  more  than  one  flow  of  steps  (branch) 
and  they  are  to  be  performed  concurrently. 

3  . 

Ia  Ib 

_ 

c  Id  Ie 

Sub-process 

(task) 

A  step  that  is  a  process  in  itself  but  for  clarity  the 
additional  steps  are  hidden.  A  sub-process  is  used  when 
the  SOP  refers  to  another  SOP. 

n  1 

Sub  Process 

Flow  lines 

All  figures  are  connected  by  lines.  The  lines  show  which  is 
the  next  step  in  the  process. 

- ► 
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Name 

Step  description 

Symbol 

Connector 

Extends  the  flow  line  without  the  entire  line  being  drawn 
across  the  workspace. 

^ O  0- 

Finish 

The  end  point  of  the  process  stating  the  achieved  end  goal. 
More  than  one  Finish  may  exist  in  a  process  if  there  is  more 
than  one  branch  to  follow. 

6  1 

/  \ 

Output  and 

Outcome 

V _  _ / 
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Appendix  C:  Example  SOP:  Man  Overboard  -  Witness 

SOP 

This  SOP,  detailing  the  steps  a  witness  to  a  person  falling  overboard  should  follow,  was 
created  using  a  stand-alone  copy  of  4TQ  Toolkit  version  6.19. 

The  procedure  looks  different  to  that  described  in  the  example  in  Appendix  A  because  this 
SOP  is  from  the  perspective  of  the  witness  to  a  man  overboard. 


THIS  PROCEDURE  IS  ISSUED  AS  AN  UNCONTROLLED 

DOCUMENT 

NO  FURTHER  AMENDMENTS  WILL  BE  ISSUED 


Man  Overboard  -  Witness  SOP 


Document  Reference  Number 

Controlled  Process 

No 

Version 

Status 

Draft 

Created 

1/03/2013 

Modified 

22/08/2013 

Approved 

Process  Owner 

Not  Approved 

EXEC 

Prepared  By 

Company 

Branch 

Sandra  Tavener 

DST  Group 
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1.  Review  Schedule 

Next  Review  Scheduled  For  2/08/2014 

2.  Process  Summary 

SOP  OBJECTIVE 

To  successfully  recover  a  person  if  they  have  fallen  over  the  side  of  the  ship.  The  medical 
treatment  of  the  person  is  covered  by  a  different  SOP. 

START  STATE 

No  prior  activities  are  assumed. 

END  STATE 

Man  overboard  recovered  onto  the  ship  ready  to  be  handed  over  to  medical  personnel. 

Ship  returned  to  previous  duties. 

ASSUMED  SHIP  STATE  /  ENVIRONMENTAL  CONDITIONS 
Any  ship  readiness  state  or  environmental  condition. 

Assumed  ship  at  sea. 

TARGET  AUDIENCE 
Any  person  on  board  the  ship. 

ASSUMED  BACKGROUND  KNOWLEDGE 

Either  basic  sailor  training  or  have  received  the  ship's  induction. 

AUTHORITATVE  /  INFORMATIVE  SOURCES 
HMAS  Choules  ship  crew. 

REFERENCES 
ABR  123 
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3.  Process  Chart 


0  Onboard  personnel 

C  I 

Witness  Man  Overboard 

- - y 


32 


UNCLASSIFIED 


UNCLASSIFIED 


DST-Group-TR-3137 


Part  2 


19  4- 


Person  recovered.  Ship 
returned  to  previous 
duties 


REPEAT  UNTIL  DIRECTED  TO  DO  OTHERWISE 


10  +  Onboard  personnel 


Keep  /  regain  sight  of 
MOB  and  point  at  them 


11.  Get  off  the  phone  if 
required 


12  ^  Onboard  personnel 


Note  MOB's  position 


13 


Onboard  personnel 


At  3  min  intervals  report 
MOB  position  to  the 
bridge  on  ext  268 
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4.  Process  Detail 

4.0  Witness  Man  Overboard 

4.0.1  Trigger  Event 

Witness  a  person  fall  overboard. 

Performer  Onboard  personnel 

4.1  Do  both  actions  (1) 


Performer  No  Performer 

The  next  figure  for  "A"  is 

4.2 

Release  nearest  lifebuoy 

The  next  figure  for  "B"  is 

4.3 

Raise  verbal  alarm 

4.2  Release  nearest  lifebuoy 

4.2.1  Description 

Locate  the  nearest  life  buoy  and  release  it  close  to  but  not  onto  the  person  in  the  water. 

4.2.2  Refs  /  Quals  /  Resources 

Lifebuoy  stations. 

Performer  Onboard  personnel 

The  next  figure  is  4.4  Raise  alarm  using  push  buttons 


4.3  Raise  verbal  alarm 

4.3.1  Description 

Shout  loudly  "Man  overboard". 

4.3.2  Refs  /  Quals  /  Resources 

Shout  loudly  but  clearly. 

Performer  Onboard  personnel 

4.4  Raise  alarm  using  push  buttons 

4.4.1  Description 

If  push  buttons  are  nearby  push  the  'Man  overboard'  button. 

4.4.2  Refs  /  Quals  /  Resources 

Resource:  Push  button  alarms  accessible  from  the  deck. 

Performer  Onboard  personnel 

4.5  Closed  up  during  RASSSD? 

4.5.1  Description 

Is  the  ship  closed  up  for  Refuel  At  Sea  Special  Sea  Duty? 

Performer  Onboard  personnel 

The  next  figure  for  "No"  is  4.6  Contact  Bridge  on  ext  268 

The  next  figure  for  "Yes"  is  4.15  Contact  Lifebuoy  sentry  on  ext  1 1 1 
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4.6  Contact  Bridge  on  ext  268 

4.6.1  Description 

Using  nearest  ship  phone  contact  the  bridge  on  ext  268. 

4.6.2  Refs  /  Quals  /  Resources 

Resource:  Phone 

Performer  Onboard  personnel 

4.7  Simultaneous  (1) 

Performer  No  Performer 

The  next  figure  for  "A"  is  4.8  Say  "Man  overboard  starboard/port  side  fwd/aft" 

The  next  figure  for  "B"  is  4.14  MOB  -  Bridge  SOP 

4.8  Say  "Man  overboard  starboard/port  side  fwd/aft" 

4.8.1  Description 

Tell  the  bridge  from  where  the  person  fell.  Include  over  which  side  (starboard  or  port)  and 
whether  it  was  forward  or  aft  of  midships. 

4.8.2  Refs  /  Quals  /  Resources 

Resource:  Phone 

Performer  Onboard  personnel 

4.9  Remain  on  the  phone  and  report  details 

4.9.1  Description 

Remain  on  the  phone  and  report  to  the  bridge  your  ID,  the  ID  of  the  person  overboard  (if 
known),  and  other  relevant  information. 

Performer  Onboard  personnel 

4.10  Keep  /  regain  sight  of  MOB  and  point  at  them 

4.10.1  Description 

Get  off  the  phone  if  required. 

Performer  Onboard  personnel 

4.12  Note  MOB's  position 

4.12.1  Description 

Note  the  position,  relative  to  the  ship,  of  the  person  overboard. 

Performer  Onboard  personnel 

4.13  At  3  min  intervals  report  MOB  position  to  the  bridge  on  ext  268 

4.13.1  Description 

At  3  minute  intervals  report  to  the  bridge  on  ext  268  the  person  overboard's  position  wrt  the 
ship. 

Performer  Onboard  personnel 

The  next  figure  is  4.19  Person  recovered.  Ship  returned  to  previous  duties 
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4.14 MOB -Bridge  SOP 

4.14.1  Description 

SOP  covering  Bridge  actions  to  take  when  notified  of  a  person  overboard. 

4.14.3  Work  Instruction 

MOB_Bridge.FLWUnable  to  find  file 

Performer  Bridge  watch 

The  next  figure  is  4.19  Person  recovered.  Ship  returned  to  previous  duties 

4.15  Contact  Lifebuoy  sentry  on  ext  111 

4.15.1  Description 

Contact  the  nearest  life  buoy  sentry  on  ext  1 1 1  using  internal  phone. 

4.15.2  Refs  /  Quals  /  Resources 

Resource:  Phone 

Performer  Onboard  personnel 

4.16  Simultaneous  (2) 

Performer  No  Performer 

The  next  figure  for  "A"  is  4.17  MOB  -  Lifebuoy  sentry  SOP 

The  next  figure  for  "B"  is  4.18  Follow  lifebuoy  sentry  directions 

4.17  MOB  -  Lifebuoy  sentry  SOP 

4.17.1  Description 

SOP  covering  Life  buoy  sentry  actions  to  take  when  informed  of  a  Man  Overboard  situation. 

4.17.3  Work  Instruction 

MOB_Lifebuoy  sentry. FLW  Unable  to  find  file 

Performer  Lifebuoy  sentry 

The  next  figure  is  4.14  MOB  -  Bridge  SOP 

4.18  Follow  lifebuoy  sentry  directions 

4.18.1  Description 

Follow  directions  as  given. 

Performer  Onboard  personnel 

4.19  Person  recovered.  Ship  returned  to  previous  duties 

4.19.1  Output 

Upon  the  completion  of  the  rescue  of  the  person  overboard,  all  personnel  return  to  the 
activity  being  performed  before  the  Man  Overboard  incident,  unless  directed  to  do  otherwise. 

Performer  No  Performer 

5.  Compliance  Issues 
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Performers 

Performer 

4.0 

4.2 

4.3 

4.4 

4.5 

4.6 

4.8 

4.9 

4.10 

4.12 

4.13 
4.15 

4.18 

Performer 

4.17 

Performer 

4.14 

Performer 

4.19 

Groupings 

Members  Of 
4.10 

4.12 

4.13 


Onboard  personnel 
Witness  Man  Overboard 
Release  nearest  lifebuoy 
Raise  verbal  alarm 
Raise  alarm  using  push  buttons 
Closed  up  during  RASSSD? 

Contact  Bridge  on  ext  268 

Say  "Man  overboard  starboard/port  side  fwd/aft" 

Remain  on  the  phone  and  report  details 
Keep  /  regain  sight  of  MOB  and  point  at  them 
Note  MOB's  position 

At  3  min  intervals  report  MOB  position  to  the  bridge  on  ext  268 

Contact  Lifebuoy  sentry  on  ext  1 1 1 

Follow  lifebuoy  sentry  directions 

Lifebuoy  sentry 

MOB  -  Lifebuoy  sentry  SOP 

Bridge  watch 

MOB  -  Bridge  SOP 

No  Performer 

Person  recovered.  Ship  returned  to  previous  duties 


REPEAT  UNTIL  DIRECTED  TO  DO  OTHERWISE 
Keep  /  regain  sight  of  MOB  and  point  at  them 
Note  MOB's  position 

At  3  min  intervals  report  MOB  position  to  the  bridge  on  ext  268 


Run  Files 

There  are  no  Figures  with  'Run  File' 

Sub  Processes 

Work  Instruction  MOB_Bridge.FLW 

Unable  to  find  file  MOB_Bridge.FLW 

Is  referenced  from: 

4.14  MOB  -  Bridge  SOP 

Work  Instruction  MOBJJfebuoy  sentry.FLW 

Unable  to  find  file  MOBJJfebuoy  sentry.FLW 

Is  referenced  from: 

4.17  MOB  -  Lifebuoy  sentry  SOP 
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